Java: File constructor path sanitizer
#18504
Conversation
jcogs33
force-pushed
the
jcogs33/java/file-constructor-path-sanitizer
branch
from
4dc7562 to
7837ad6
Compare
jcogs33
force-pushed
the
jcogs33/java/file-constructor-path-sanitizer
branch
from
8ef7637 to
60cc16c
Compare
There was a problem hiding this comment.
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
Comments suppressed due to low confidence (1)
java/ql/test/library-tests/pathsanitizer/Test.java:482
- Several consecutive blocks (lines 480–610) repeat similar path validation logic. Consider extracting this shared logic into a utility method or parameterized test to simplify and reduce duplication.
File f1 = new File("safe/file.txt");
Tip: Copilot code review supports C#, Go, Java, JavaScript, Markdown, Python, Ruby and TypeScript, with more languages coming soon. Learn more
| src.asExpr().(MethodCall).getMethod().getName() = "source" | ||
| } | ||
|
|
||
| predicate isSink(DataFlow::Node sink) { exists(Call call | sink.asExpr() = call.getAnArgument()) } |
There was a problem hiding this comment.
I worry this could be a performance problem - finding all global flow to arguments of calls. Better to make it more specific - something like any(ConstructorCall constrCall | constrCall.getConstructedType() instanceof TypeFile).getArgument(0).
There was a problem hiding this comment.
Yes, I'm also concerned about that, which is why I'm currently running DCA.
Based on previous experimentation with this, I don't think restricting to ConstructorCall will necessarily be any better, but I'll give it a try if my current DCA experiment shows bad performance.
Do we have any better/pre-built way of checking whether an expression is tainted that doesn't require making a global TaintTracking config?
There was a problem hiding this comment.
Yep, performance is bad. Running DCA on the ConstructorCall version to see if there's a difference.
There was a problem hiding this comment.
The ConstructorCall version still has bad performance (although not as bad as the Call version).
| // for InlineFlowTest | ||
| src.asExpr().(MethodCall).getMethod().getName() = "source" |
There was a problem hiding this comment.
This is fine for testing, but we shouldn't commit this. I'm sure we can find some other solution, like adding a model to the inlineflowtest so that source is a remote flow source.
There was a problem hiding this comment.
Can you clarify what you mean by "adding a model to the inlineflowtest"? I was thinking of using an actual ActiveThreatModelSource in this test case instead of (File) source();. Is that what you mean? Or did you have something else in mind?
There was a problem hiding this comment.
I meant you could add a model for source as a remote flow source that applies just to this test (if the test is x.ql then the model has to be in a file called x.ext.yml in the same folder). That way the inline flow test can use its way of finding sources (calls to "source") and this flow config can use its way (active threat model). An alternative approach is to change the test to use ActiveThreatModel for its sources, which I think is what you were suggesting. Both are fine.
Description
Adds a path injection sanitizer for the
childargument of ajava.io.Fileconstructor when that argument is normalized or checked for the absence of "..".Consideration
Note that sanitizing the second argument of the
Fileconstructor also sanitizes other uses of that variable after the constructor call (see theMISSINGcases in the tests). Let me know if there is some way to adjust the QL to avoid also sanitizing these other uses. I can sanitize theFileconstructor call instead of the second argument, but then the first argument needs to be checked for taint.Pull Request checklist
All query authors
Internal query authors only